In general, clusters are groups of computer systems, which can provide advantages in availability (service uptime) through redundant hardware. For example, if systems A and B are in a cluster together and system A fails, then its workload can be relocated to system B. In clusters that involve more systems (or “nodes” in cluster parlance), the specification of the workload relocation can be more complex. Clusters manage “resource groups”, which are taken to be a collection of resources (hardware or software) that provide a service to clients and can be treated as a unit. The specification of the full configuration model of a cluster and DB2 instances contained within it can be both error prone and time consuming, given the large amount of data which must be specified. This is further complicated by the fact that different cluster managers (the software packages that manage clusters) have different models of the software and hardware that the cluster contains; for example, Oracle's RAC system provides a clustered database manager instance and comes with associated configuration tooling. However, as of the 10 g release it appears that the hardware (node/NIC/network) and database configuration steps are handled by separate tools. RAC is also tightly coupled with Oracle's own cluster manager and thus provides no cluster-independent abstraction. Additionally, most database administrators are not familiar with clustering or its associated terminology, which creates usability issues when databases must be clustered. These problems have been observed in general in many types of service provider networked database cluster applications. Thus, problems with configuring networked database clusters for high availability are not limited to the above mentioned applications. Other applications and vendors are similarly affected.
Therefore, the need exists for a modeling system that permits the user to specify the configuration of a clustered database instance in terms of familiar hardware (node/system, network interface, network) and database (instance, database, path) objects; thus, causing the specification of the full configuration model of a cluster and DB2 instances contained within to contain few errors and take a reduced amount of time to prepare, given the large amount of data which must be specified.
Further the need exists for a modeling system where these objects are contained in a unified model where the configuration is specified at a logical level that is independent of the 3rd party cluster manager, which manages the configuration. This provides a complete specification of the cluster configuration within a single modeling tool for specifying the configuration of different cluster managers that have different models of software and hardware and permits the user to take a logical “snapshot” of the cluster's configuration.
Finally, the need exists for a modeling system that allows for easy version-to-version migrations of DB2 instances, which can require different specifications to the underlying cluster manager, as well as simplifying cluster manager to cluster manager migrations, because most database administrators are not familiar with clustering or its associated terminology, which creates usability issues when databases must be clustered.